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ABSTRACT 



Shiptracks are known to be a relatively common phenomenon, often appearing in 
AVHRR channel 3 imagery as anomalous, curvilinear cloud lines. Despite their 
significance to remote ship surveillance studies, the formation mechanisms responsible 
for shiptrack production are still largely unknown and their specific characteristics still 
undefined. 

A shiptrack detection algorithm being developed at the Naval Postgraduate School 
seeks to objectively detect and locate shiptracks on AVHRR imagery. This algorithm is a 
major step in objectively defining specific shiptrack characteristics and automating the 
search for additional shiptrack examples. The purpose of this study was to outline the 
logic of the detection algorithm and present a subjective performance smnmary of its 
usefiilness. 

After careful analysis of the algorithm output files on several full satellite passes, it 
was determined that the algorithm is capable of successfully detecting up to 65% of the 
fresh shiptracks within a full pass AVHRR image with a false detection rate of only 1 .3 1 
tracks per million square kilometers. This performance is likely to improve further with 
continued work focused on designing adequate filters to categorically reject many of the 
recurring false detections. 



m 



! kb 0!^ 

tj 



TABLE OF CONTENTS 

l. INTRODUCTION 1 

A. BACKGROUND 1 

B. MOTIVATION 3 

C. OBJECTIVES 7 

n. SATELLITE DATA COLLECTION AND PROCESSING 9 

A. SATELLITE 9 

B. SENSOR. 10 

C. CHANNELS USED 1 1 

m. SHIPTRACK DETECTION ALGORITHM 1 3 

A. THE LOGIC 14 

1. Foreman 15 

2. Getimgl , Getimg2, Getimg3 1 5 

3. Census 18 

4. Neighborhood 19 

5. Roadway 20 

a. Indexgen 21 

b. Survey 21 

c. Pave 22 

(1) Gravel 25 



IV 



(2) Landscape 


DUDLEY KNOX LIBRARY 
NAVAL POSTGRADUATE SCHOOl 
MONTEREY CA 93943-5101 

27 


6. OutimgO 


31 


B. OUTPUT. 


31 


IV. PROCEDURES 


32 


A. PHASE 1 


33 


B. PHASE 2 


34 


V. RESULTS 


39 


A. PHASE 1 


39 


B. PHASE 2 


44 


1. Case study 1 


45 


2. Case study 2 


46 


3. Case study 3 


46 


4. Case study 4 


47 


5. Summary 


47 


C. FALSE DETECTIONS 


48 


VI. CONCLUSIONS AND RECOMENDATIONS 


92 


A. FALSE DETECTIONS 


93 


B. ALGORITHM MODMCATIONS 


93 


LIST OF REFERENCES 


95 


INITIAL DISTRIBUTION LIST 


96 



V 



ACKNOWLEDGEMENTS 



I would like to extend a special thank you to Kurt Nielsen of the NavalPostgraduate 
School for his patience and support throughout this project. Kurt was responsible for 
writing the original algorithm and for taking the time to painstakingly help me dissect and 
analyze his work. 

I am also grateful to Professors Phihp Durkee and Carlyle Wash for their technical 
support and encouragement and of course to my wife (Amy) and daughter (Amanda) for 
their moral support on the home front 



VI 



I. INTRODUCTION 



A. BACKGROUND 

Anomalous cloud lines were first recognized in the summer of 1965 from a 
TDR.OS-IV (visible) satellite image southeast of the Kuril Islands. The image showed 
three long, plume-like cloud lines that crossed a large-scale cloud pattern at high angles, 
the longest of the cloud lines being 350 km long and 5 to 24 km wide. Carefiil inspection 
of the image suggested that the cloud lines were at an altitude near that of the large-scale 
band of clouds and were probably warmer than freezing. It was further suggested that 
their origin was anthropagenic, with possible sources given as stationaiy ships such as 
whaling vessels or factory ships that released large quantities of water vapor as they 
processed their catch at sea (Conover, 1966). 

After conducting an exhaustive search for additional anomalous cloud line images, 
Conover published his conclusions on anomalous cloud line formation mechanisms based 
on the 16 known cases to date. He concluded that "the most likely cause of the cloud 
lines stems from exhaust from ocean going vessels. Large numbers of Aitken nuclei 
form in this exhaust. These are carried upward by the buoyancy of the hot gasses and 
"ship's air wake" to form droplets at slight supersaturation. This phenomenon does not 
appear related to special characteristics of the vessels power plant but to a critical 
condition of the atmosphere." 

This early work demonstrated that under certain atmospheric comhtions, the exhaust 
from ocean going vessels can result in the formation of anomalous cloud lines visible 
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from space in the visible wavelengths. It wasn't until 1987 however, when it was 
discovered that these same mechanisms produced similar cloud lines in pre-existing 
marine stratus clouds in the near infrared (3.7 fim), that the shiptrack phenomenon began 
to generate great interest from climatologists and more recently, leaders in Naval 
Intelligence. 

This increased interest began when Coakley et al (1987) first described the shiptrack 
phenomenon based on observations made with NOAA Advanced Very High Resolution 
Radiometer (AVHRR) in the near-infrared and continued on into 1991 when a frequency 
of occurrence study off of the West Coast of the United States suggested that the 
phenomenon is relatively common in this high ship traffic density region, especially 
during the summer months (Durkee and Lutz, 1991). Coakley et al. observed that under 
stable meteorological conditions the effect of ship-stack exhaust on overlying marine 
stratus clouds is to increase the number of cloud droplets while decreasing the cloud 
droplet size, resulting in an increase in the reflectance of the cloud at 3.7 p.m (and to a 
lesser extent 0.63 |im). Remote and in-situ measurements of shiptrack modified clouds 
made by Radke et al (1989) and Hindman et al (1990) indicate that the shiptracks contain 
a higher number of smaller cloud droplets and an increased liquid water content than the 
surrounding ambient cloud. 
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B. MOTIVATION 



The fonnation mechanisms that produce shiptracks at sea are still not completely 
understood. Yet, when one looks at the effects that man-made aerosols have on the 
global climate, the shiptrack phenomenon may represent an effect several times more 
influential in modifying the local radiation budget than that of direct interaction of solar 
radiation with the ship produced aerosol particles themselves (Coakley et al, 1987). A 
thorough understanding of the effects of man-made aerosols on the reflectance of 
pre-existing clouds and their associated effects on the radiation budget is fundamental in 
completely understanding the effects of increasing levels of man-made aerosol emissions 
into the atmosphere. Essential to this understanding, and a logical place to focus the 
study, is in determining the necessary atmospheric conditions and fonnation mechanisms 
that produce shiptracks. 

Shiptracks generally appear in near-infrared (near-IR) imagery, centered at 3.7 pm, as 
bright, curvilinear anomalies within marine stratiform clouds (Fig. 1). They tend to 
maintain a fairly constant width and brightness despite their persistence over several 
hundreds of kilometers. They range in width from roughly 7 to 10 km near their head 
and up to 25 km towards their trailing ends. In visible (VIS) imagery, centered at 
0.63 pm, the same shiptracks do not always stand out, often appearing only slightly 
brighter than the surrounding cloud (Fig. 2). Finally, in infrared imagery (IR), centered at 
11.0 pm, shiptracks do not appear at aU. Cloud regions where shiptracks are known to be 
appear simply as ordinary medium to low level stratiform clouds in the infrared (Fig. 3). 
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Mgure 1. AVIIRR channel 3 image taken by NOAA-9 on July 13, 1987 
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Figure 2. AVHRR chiuincl 1 image taken by N'0^\^\-9 on July 13, 1987 
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l'’i^»ure 3. AVllRR 4 image Uiken by NOAA-9 ou July 13, 1987 
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The shiptrack phenomenon is of particular interest to tlie Navy for its potential 
applications in remote ship surveillance. Until recently, potential enemy battle group 
movements could be detected from space only during daylight hours and imder clear 
skies. Because shiptracks can be seen in marine stratus clouds in the near-infrared, they 
present an opportunity to fill in some of the time and area gaps in relocating a battle 
group lost under cloud cover. With the present technology shiptracks can only be used to 
approximate ship traffic density, individual ship positions and their relative courses and 
speeds. It is hoped that a thorough study of shiptracks will reveal an exploitable, long 
range, detection method for certain ship classes (i.e. size and/or powerplant) along with 
possible counter-detection procedures for our own forces. 



C. OBJECTIVES 

Shiptracks, like all cloud features, are extremely diverse. Distingjiishing a shiptrack 
from the surrounding cloud features can often be very subjective, especially in regions 
where the clouds have naturally occurring sharp, linear features. It becomes more 
difficult to follow a shiptrack further away from its head. This subjectivity emphasizes 
the need to objectively define and locate shiptracks using characteristics of the image in 
the visible, near-infrared and infrared wavelengths. Removing the subjectivity in finding 
shiptracks is the first step in systematically analyzing and understanding shiptracks. 

A second problem facing researchers is the time required to sift through the enormous 
quantity of satellite tapes to find a statistically valid number of shiptracks in which to 
base a study. Currently, an AVHRR satellite pass takes about 20 minutes to process 
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before it can be viewed. In order to get the resolution necessary to adequately see 
shiptrack features, the image must be blown-up (painted) frame by frame, often taking up 
to several hours to manually scan the entire image. 

The most efficient way to objectively locate shiptracks on satellite images is by using 
a computer based shiptrack detection algorithm that can scan an entire satellite pass and 
use specific, known characteristics of shiptracks to distinguish the shiptracks from the 
surrounding cloud. One such algorithm is being developed here at the Naval 
Postgraduate School by Kurt Nielsen (under the direction of Professor Phil Durkee). It is 
the objective of this thesis to: 1) Outline the logic and various optional control parameter 
settings found in the current shiptrack detection algorithm, 2) Empirically dete rmin e the 
most efficient option settings of the algorithm based on a single, multiple-shiptrack 
satellite image and, 3) Present a performance summary of the algorithm on several 
AVHRR images. 
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II. SATELLITE DATA COLLECTION AND PROCESSING 



The shiptrack detection algorithm is designed to work on Advanced Very High 
Resolution Radiometer (A VHRR), High Resolution Picture Transmission (HRPT), 
images taken from the National Oceanic and Atmospheric Administration (NOAA) polar 
orbiting satellites. The data stream is typically archived on standard 9-track magnetic 
tapes, each of which hold up to 7 minutes of data. Satellite images are processed from 
the raw data in the U.S. Naval Postgraduate School's Interactive Digital Environmental 
Analysis (IDEA) laboratory by a network of VAX 8250 computers. Once processed, the 
shiptrack detection algorithm can be run and the image viewed in full (at a reduced 
resolution) orin512x512 pixel blocks (at full resolution). 

A. SATELLITE 

The current Polar Orbiting Operational Environmental Satellite (POES) flown by 
NOAA is the Advanced TEROS-N (ATN). The satellites themselves, two of which are 
flying at any given time, are in Sun-synchronous, circular orbits at altitudes of 
approximately 850 km. Under normal conditions, one satellite will be in an orbit with a 
southbound equator crossing time at about 0730 local solar time (LST), the other with a 
northboimd equator crossing time at about 1430 LST. These orbits are selected to 
provide maximum global coverage within the limitations imposed by the communications 
and data handling facilities and the time-lines needs of data users (Rao et al, 1990). 
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The primary POES missioo is to provide daily global observations of weather 
patterns and environmental conditions in the form of quantitative data usable for 
nmnerical weather analysis and prediction. POES spacecraft are used to observe and 
derive cloud cover, ice and snow coverage, surface temperatures, vertical temperature and 
humidity profiles. 

B. SENSOR 

The AVHRR is a scanning radiometer carried by the ATN that is sensitive to the VIS 
and near-IR, and IR "window" regions. Data is retained from a swath extending 55.4 
degrees to either side of nadir (2048 pixels per scan per channel) having a resolution of 
1.1 km directly below the satellite. Tlie sensor records the Earth's radiation in five 
wavelengths, one in the visible, one in the near-visible and three in the infrared (Table 1). 
The data is transmitted to ground stations for distribution as 1.1 km resolution. High 
Resolution Picture Transnussion (HRPT) data. Of particular interest to this study are the 
visible, near-infrared and thermal infrared HRPT data, (AVHRR channels 1 , 3 and 4 
respectively). 
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C. CHANNELS USED 



In general, shiptracks are best seen in the near-IR channel 3 imagery. It is in this 
channel that all of the searching by the shiptrack detection algorithm for potential 
shiptracks occures. This c hann el is calibrated in units of radiance. Because channel 3 is 
in the near-ER, the daylight radiance observed from the satellite has contributions from 
both solar reflectance and thermal emission. By utilizing a method described by Allen 
(1987), the thermal emission portion of the total radiance at this wavelength can be 
subtracted out leaving only the reflected contribution. In this study, both types of channel 
3 data are used and will be referred to as simply channel 3 data (solar reflectance and 
thermal emission) and Low3 (solar reflectance only). 

The shiptrack detection algorithm uses data from channel 1(VIS) in various filter tests 
(which wUl be described in more detail in chapter 3) to help reject natural features which 
may look like shiptracks in channel 3 imagery. The data is calibrated in terms of albedo 
and is converted to units of percent reflectance. This conversion is based on weighting 
the received reflectance by the cosine of the solar zenith angle and the anisotropic 
reflectance factor (Allen, 1987). 

The algorithm uses channel 4 (IR) data in much the same way it uses the channel 1 
data. The data is the result of thermal emission and is converted to a radiance 
measurement with units of radiance by using a linear correlation to counts. 



11 



TABLE 1 

AVHRR CHANNELS 



CENTER 

CHANNEL WAVELENGTHS(um) WAVELENGTH PRIMARY USES 



1 


0.58-0.68 


0.63 


Daytime cloud/surface 
mapping 


2 


0.725-1.10 


0.83 


Surface water delineation, 
ice and snow melt 


3 


3.55-3.93 


3.70 


Sea surface temperature, 
night-time cloud mapping 


4 


10.30-11.30 


11.00 


Sea surface temperature, 
day/night cloud mapping 


5 


11.50-12.50 


12.00 


Sea surface temperature, 
day/night cloud mapping 
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III. SfflPTRACK DETECTION ALGORITHM 



The goal of this chapter is to outline the processing steps, the detection logic and the 
sub-programs used to detect shiptracks. Hie shiptrack detection algorithm processes a 
full-pass AVHRR satellite image, using c hann el 1, 3 and 4 data to objectively locate 
shiptracks. The algorithm uses three (2048 x N pixels) files containing the channel 1 , 3 
and 4 data as inputs and returns a corresponding summary output file containing locations 
in the image where possible shiptracks can be found. The input files must be created 
using a program utility (cdiliXQ&Datadwnp), which converts the individual channel data 
from the satellite t^es to real data files, and a program (called real2byte) which then 
converts the real data files to a fixed record length byte file format that the algorithm can 
accept. The output file can be viewed directly by the user after it has been condensed to a 
512x512 fixed record length file (using a program called fixcondO). Once a satellite 
pass is loaded and processed, the steps taken to produce an output file can eventually 
become automated. This will allow the user to select a satellite pass overview, initiate the 
program, and come back several hours later to observe the results. 

The detection code is composed of 13 separate modules which utilize 20 control 
parameters. This rather large computer program is required to do objectively what the 
human eye can do (albeit somewhat subjectively) at a glance. Shiptracks often stand out 
from their surroundings in channel 3 imagery as being long, curvilinear features of sharp 
contrasting brighmess. Because the human eye can view an entire image at once, it is 
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able to fill in small gaps in the linearity where the shiptrack contrast with the surrounding 
cloud diminishes. With the present technology, it is not possible to reproduce what the 
eye can do so a rather complicated algorithm is required to enable a computer to detect 
shiptracks while only being able to process small sections of the image at a time. 

A. THE LOGIC 

The core of the program is a main do-loop which calls the 13 subroutines. Of these 
subroutines, 5 are administrative, dealing with such things as loading and manipulating 
the images and inputting the various control parameters, while the remaining 8 do most of 
the detection work, ITiese 8 subroutines focus on detecting various generic shiptrack 
characteristics and ultimately pass their findings back to the administrative subroutines 
which record a shiptrack image onto a giant output image file. Due to memory 
limitations of the VAX computer, a main do-loop must break down the giant input 
images into 512x512 area images (hereafter referred to as block images) and feeds them 
one at a time to the subroutines for analysis. A shiptrack image file is created for each of 
the block unages by the subroutines and passed back to the main program. A final 
subroutine is then called which maps the shiptrack image onto a giant output image file. 
This loop repeats itself until the entire giant input image is processed. 

A detailed presentation of the algorithm logic is best handled by analyzing each 
subroutine separately in the order in which it is called by the main program. Since 
shiptracks are like long cloud "roads", coostniction terms are used to describe each 



14 



subroutine within the automated detection algorithm. The first call is to the subroutine 
Foreman which loads the user-selected control parameters into memory for use by the 
remaining subroutines inside the main do-loop. Once these settings are loaded, the 
program enters the main do-loop where the remaining subroutines are called to detect 
shiptracks and record their findings in the output file (Fig. 4). 

1. Foreman 

This subroutine finds and loads the 20 control parameters which are stored in a 
separate list file for easy manipulation. The parameters are listed in Table 2 along with 
the subroutine in which they are called and typical values of each parameter. Each of the 
parameters will be described in detail when the appropriate subroutine is discussed. 

2. Getimgly Getimg3, Getimg4 

These subroutines read in block images from the giant channel 1, 3 and 4 byte files 
and map them into corresponding block files called IMGl, IMG3 and IMG4 respectively. 
GetimgS performs a conversion of the IMG3 data from byte to integer, resulting in a two 
dimensional array of integer chaimel 3 brightness values. IMGl and IMG4 are initially 
left as byte arrays, which take up only 1/4 of the space of a corresponding integer array, 
and can be stored in this compact form until needed. 
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MAIN DO-LOOP 



START 
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TABLE 2 

CONTROL PARAMETERS CALLED 
IN SUBROUTINE FOREMAN 

NAME SUBROUTINE TYPICAL VALUE 



FACT 


CENSUS 


1.4 


STDMIN 


CENSUS 


5 


TLOW 


CENSUS 


273 


TfflGH 


CENSUS 


299 


CUTOFF 


NEIGHBORHOOD 


8 


RADIUS 


ROADWAY 


50 


THRESH3(1) 


PAVE 


1 


THRESH3(2) 


PAVE 


8 


THRESH3(3) 


PAVE 


88 


PATHRESH 


PAVE 


80 


PATHGRAD 


LANDSCAPE 


8 


THRESH3WD 


LANDSCAPE 


80 


GRAVl 


GRAVEL 


70 


GRAV2 


GRAVEL 


25 


GRAV3 


GRAVEL 


10 


GRAV4 


GRAVEL 


10 


BOGUS 1 


GRAVEL 


60 


BOGUS2 


GRAVEL 


60 


BOGUS5 


GRAVEL 


50 


BOGUS6 


GRAVEL 


10 
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Conversion of the whole IMG3 array is done because the algorithm scans the entire 
channel 3 image looking for potential shiptrack features and requires c hann el 3 brightness 
counts (in integer form) for its initial search. The IMGl and IMG4 array data are used in 
subsequent subroutine checks on prospective shiptrack features and are converted to 
integer form as needed. 

3. Census 

Census examines the IMG3 data and maps each pixel that exceeds certain brightness 
and temperature thresholds into an initially null giant working array (IMGO) as a code 1. 
Specifically the subroutine breaks the channel 3 block image up into 16x16 subareas and 
computes the mean and standard deviation for each. It then converts the corresponding 
subarea portion of the IMG4 array to integer form and calculates the temperature of each 
pixel. Provided the subarea has a sufficient variation in channel 3 pixel brightness 
(subarea standard deviation greater than Stdmin), each pixel within that subarea which has 
a channel 3 brightness count greater than the control parameter fact multiplied by the 
subarea standard deviation and a temperature within Tlow and Thigh, is flagged, and its 
position mapped as a code 1 in the working array. If the subarea standard deviation is 
below the control parameter Stdmin, the entire subarea is mapped as O's in the working 
array. 
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4. Neighborhood 

The neighborhood subroutine is designed to screen the "brighl" pixels found in 
Censtds for randomness. Shiptracks tend to be long, linear, bright features in channel 3. 

If the "bright" pixels found in Census are randomly dispersed (ie, do not fonn linear 
patterns), they are likely not part of a shiptrack. 

The subroutine breaks the working array (IMGO) into 16 x 16 subareas and counts 
each code 1 pixel. A separate 16x16 "neighborhood" array is c»'eated that maps the 
number of code 1 pixels located within +/- 2 pixel lengths from each pixel location in the 
IMGO array. Pixels in IMGO that have a corresponding "neighborhood" count in the 
neighborhood array that is greater than Cutoff are flagged and re-mapped as code 2's back 
in IMGO. This procedure ensures that only sufficiently "clumpy" bright areas are 
considered as potential shiptrack elements as opposed to randomly distributed bright 
pixels. 

Finally a neighborhood representative is chosen from aU of the code 2's within each 
subarea based on brighmess. The brightest code 2 pixel within the subarea is flagged and 
re-mapped as a code 3 within IMGO. The end result is a working array of I's, 2's and 3's, 
with the 3's being the essential information required by the next subroutine called 
Roadway. 
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5. Roadway 



The objective of Roadway is to analyze path segments connecting neighborhood 
representatives to determine whether the segments meet certain criteria that are 
characteristic of shiptracks. The subroutine itself calls upon 5 of the remaining 6 
subroutines and all (1 5) of the remaining control parameters used in the algorithm. Like 
Census and Neighborhood, Roadway uses IMGO as the working array. Possible 
shiptrack path segments connecting the neighborhood representative (3’s) are initially 
coded as 4's in an in-house array and are mapped as 5's in IMGO if the paths are found to 
meet the various criteria defined by the control parameters to be discussed. The working 
array in this form is what makes up the output file of the algorithm. When an image is 
created using this information, the code 5 pixel locations can be viewed separately, 
marking the locations of algorithm-accepted shiptracks. 

Roadway begins with a call to Indexgen (described below). It then begins scanning 
the block image line by line for neighborhood representatives (code 3 pixels). Once a 
representative is found, another search, centered on the representative, is conducted to 
look for other nearby representatives that may lie along a mutual shiptrack path segment. 
The search is conducted in the horizontal direction for plus or minus Radius pixel length 
units, and along the vertical (down direction only) Radius pixel length units for other 
code 3's. Once a potential shiptrack path is found, the coordinates of the representatives 
are passed on to Survey and Pave for analysis. 
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a. Indexgen 



The bulk of the testing of potential shiptrack paths involves comparing the channel 
1 , 3 and 4 pixel values along the line between two neighborhoods to those of the adjacent 
cloud. This is done by marching along the pixel path between two neighborhoods, pixel 
by pixel, and comparing the local characteristics of the path to the cloud characteristics 
found on either side of, and directly perpendicular to, the path itself. 

For each possible path orientation, the subsequent "testing” subroutines need to 
know the locations (or addresses) of the cloud pixels, out to a distance of 18 units in 
either direction, along the path perpendicular centered on each path point. To save each of 
the subsequent subroutines from having to compute these addresses each time, this is 
done only once in Indexgen. 

Eight possible path perpendicular directions are considered for simplicity. For 
each of the eight directions, an array of relative adjacent cloud pixel addresses is 
computed and stored for ready access. This information is made available in the 
subsequent testing subroutines 

b. Survey 

Survey finds the addresses (image line and element) of each pair of neighborhood 
representatives that are sufficiently close to each other (described by control parameter 
Radius) to fonn a shiptrack path segment. The subroutine connects the representatives 
with a string of 4’s, mapping each path out in a temporary memory space to be checked 



21 



by Pave, The orientation of each path are then computed and assigned one of eight 
possible orientation codes. These orientation codes are used to find the appropriate 
address array (computed by Indexgen) for the path perpendicular points used in the Pave 
checks. 

c. Pave 

Up to this point the algorithm has found sufficiently bright "neighborhoods" of 
pixels and, provided they were within a certain maximum distance apart, marked the 
paths between them as potential shiptrack segments (code 4's). Pave (with its subsequent 
calls to Gravel and Landscape) is where the actual testing of the potential paths occurs to 
determine if they exhibit properties (as defined by the control parameters) characteristic to 
shiptracks. These properties include brightness (channels land 3) and temperature 
differences with the adjacent cloud field and absolute brightness gradients in chaimels 1, 

3 and 4. 

Pave takes the addresses of neighborhood representatives that mark the ends of a 
possible shiptrack segment and the temporary roadway map generated by Survey. The 
subroutine then examines the path segment, one pixel at a time comparing the local cloud 
features along the path with those of the adjacent cloud found on both sides of the path. 
This is done by first loading the c hann el 3 brighmess information of the adjacent cloud 
into a separate 2-dimensional array that is orientated in the same direction as the path 
itself (the orientation direction and the associated pixel addresses calculated by 
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Indexgen). The subroutine then examines each I -dimensional path perpendicular array 
for each of the pixels along the path and performs brightness comparison tests between 
the different fixed subdivisions (Fig. 5) of the path perpendicular. 

The average channel 3 brightness values are computed for each of the regions. For 
all but the Subfield region, these averages are computed by simply adding the pixel 
brightness values and dividing by the number of pixel units across. In the case of the 
Subfield region, a special bias is put in to help account for shiptracks that were 
significantly narrower than the subfield region itself. This bias effectively sets the 
subfield average to the average brightness value of any two or more pixels that both fall 
wi thin the subfield region itself and are greater that the straight numerical brightness 
average within the region; essentially an average of the above average pixels. If there are 
not two or more pixels that meet this criterion, the subfield average is set to the simple 
numerical average brightness within the subfield region. Thus, when there is a 
significantly bright and narrow shiptrack, the subfield value used in the shiptrack 
path/adjacent cloud comparison tests is significantly brighter than the numerical average 
of the subfield pixels and is a better representative of the actual shiptrack than a simple 
numerical average of the subfield pixels. 

Pave performs three simple channel 3 brightness comparison tests for each pixel 
along the path segment: 1) The subfield average must be brighter than the lullfield 
average by ThreshS(l) units, 2) The subfield average must be brighter than the nearfield 
average by Thresh3(2) units and, 3) fhe farfield average minus the nearfield 
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Figure 5. Pave path perpendicular subregions 



average must be less than Thresh3(3) units. If Pathresh percent of the pixels along the 
path segment pass all three of the above tests, the path Ls sent on to Gravel and then to 
Landscape for further testing. 

1. Gravel 

Gravel is designed to filter out natural quasi-linear IMG3 features that are actually 
gaps in the clouds, edges of continents or dense middle or high cloud shields. It uses 
c hann el 1 and 4 data to reject potential shiptrack features that exhibit sharp visible 
brightness gradients (cloud gaps), and/or sharp temperature gradients (continents or high 
cloud shield edges). 

The subroutine looks at a 3 pixel wide region around each path segment point and 
a 4 pixel wide region symmetrically spaced on both sides of path along the path 
perpendicular. Within these regions, the channel 1 and 4 brighmess values are averaged 
and used to compute several variables that are subsequently used in tests designed to 
accept or reject the path segment based on visible contrasts with the surrounding cloud 
and temperature and visible gradients. Figure 6 depicts the regions along each path 
perpendicular and Table 2 lists the variables computed from the channel 1 and 4 
brightness values within those regions. 
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Figure 6. Gravel path perpendicular regions 



TABLES 

GRAVEL COMPUTATIONS 

Variables computed for each path perpendicular 

Subl = Average channel 1 brightness within the Sub region 

Sub4 = Average c hann el 4 brightness wi thin the sub region 

Faria (Farlbl = Average channel 1 brightness within Far-A (Far-B) region 

Far4a (Far4bl = Average channel 4 brightness within Far-A (Far-B) region 

Farlave = (Faria + Farlb) / 2 

Far4ave = (Far4a + Far4b) / 2 

Gradl = Farlb - Faria 

Grad4 = Far4b - FarSa 

Variables computed for the entire path segment 

Gradl ave = Average channel Ipath perpendicular gradient along the path 
Grad4ave = Average channel 4 path perpendicular gradient along the path 
Pathcount = The number of pixels along the path segment 
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The Gravel logic is best presented by way of a flow chart (Fig. 7). The 
sub-algorithm is entered with a potential shiptrack path segment and exited with an accept 
or reject flag that is sent back to Pave. Control parameters are shown in italics in the 
flow chart. Gravl is an absolute channel 1 brightness threshold. Grav2, GravS, Grav4, 
BogusS and Bogt4s6 are channel 1 and 4 gradient thresholds. Finally, Bogusl and Bogus! 
are minimum accepted path perpendicular percentage values. 

2. Landscape 

Landscape is designed to analyze potential shiptrack path segments based on 
channel 3 brightness gradients characteristics. The idea is to force potential shiptrack 
path segments to be features confined by local c hann el 3 brightness gradient maxima and 
minima. Like Gravel , Landscape analyzes and tests single path segments passed on to 
it from Pave. The subroutine performs certain gradient tests on each path perpendicular 
and requires a minimum percentage of the path perpendiculars to pass before the decision 
is made to accept or reject the path segment. 

The first thing that the subroutine does is reject path segments that are less than 
20 pixels long. This filter is essentially an arbitrary CPU time saving step that was placed 
here in the last (and most recently added) subroutine to speed up the analysis. This 
restriction could have easily been placed in Roadway where a maximum path segment 
length limi t of Radius pixels was imposed 
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Kigure 7. Gravel logic flowchart 
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The subroutine next sets out to compute the instantaneous channel 3 brightness 
gradient along each path perpendicular to define the path edges. The first step in this 
process is smoothing the brightness values along the path perpendicular. A three point 
running mean of the brightness values is computed from plus or min us 16 pixels from the 
path center. These smoothed brightness values are then used to compute a three point 
running gradient along the path perpendicular. 

Once the instantaneous gradient is computed, the subroutine finds the local (plus 
or min us 9 pixels from the path center) gradient maximum and minim um. A restriction is 
then imposed on the path segments, requiring them to have one positive and one negative 
gradient extreme and that these gradient extremes have an absolute value which is greater 
than the control parameter Pathgrad but less than an arbitrary cutoff of 40. 

The next restriction the subroutine places on the path perpendicular is to require 
the shiptrack path width to be greater than 3 pixels. This restriction is imposed to 
e liminat e accepted path segments that are actually small scale gaps on either side of thin 
quasi-linear clouds. The path width is defined as the length between the gradient 
extremes plus 2 (Fig. 8). 
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Next, the subroutine sets out to reject features having excessively noisy 
brightness gradients. This is done comparing the brightness gradients out to plus or 
miuus 15 pixels from the center to the local (plus or minus 9) gradient extremes and 
rejecting those path perpendiculars which have more than one gradient greater than or 
equal to the local gradient extremes. 

When the subroutine is through analyzing each path perpendicular, the percentage 
of those that passed the above test is computed. If this percentage is foimd to be greater 
than the control parameter ThreshSwd, the path is accepted, if uot, it is rejected. 
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6. OutimgO 

This subroutine is the final subroutine in the main do-Ioop. The working array is 
passed from the main program to OutimgO where it is written into the giant image output 
file in the corresponding positions to the original input files. 



B. OUTPUT 

The algorithm generates a giant integer output file containing a series of 2's, 3's and 
5's. The 2's correspond to bright pixels on the original channel 3 image that stand out 
from their local surroundings. The 3's map local neighborhood representatives which 
mark the ends of potential shiptrack path segments and the 5's mark the connecting points 
between these end points. By using a condensing program (fixcondO) and a utility called 
colors (which can represent each of the three integers as a separate color), this output file 
can be easily viewed on the monitor or made into hard copies. 

There are two ways to view the algorithm output with the original image to determine 
how well the particular run performed. The quickest and easiest way is to use a utility 
caUed flicker to rrqridly alternate between the original and the output images on the 
monitor. The second option is to make hard copies of the original images and 
transparencies of the output image (both on the IDEA lab's RGBEI laser printer) and 
overlay the transparency on the original image hard copy. 



31 



rv. PROCEDURES 



As described in chapter three, the current shiptrack detection algorithm has 20 
variable control parameters. Before a meaningful study could be conducted on the 
effectiveness of the algorithm at detecting shiptracks, a preliniinary deteimination of the 
optimum settings had to be made. Once these settings were established, additional 
satellite passes were chosen and the algorithm run on each pass using the optimum 
settings. The runs were then separately analyzed and the effectiveness of the algorithm 
was subjectively dete rmin ed for each. 

The project was broken down into two phases. The first phase involved choosing a 
single satellite pass that contained multiple shiptracks of varying lengths, widths and 
brightness to be used as a baseline with which to test and optimize the algorithm settings. 
The shiptrack locations were manually (subjectively) determined on the image and 
multiple runs of the algorithm were made and compared to the subjective analysis. The 
optimum settings for the algorithm were determined based on the number of detections 
and false detections of each run. 

The second phase of this study involved choosing additional satellite passes, 
subjectively determining the shiptrack locations and analyzing the results from each run 
of the algorithm (using the settings found in phase 1). The effectiveness of the algorithm 
was determined by comparing the subjective analysis to the objective analysis of the 
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algorithm by means of a series of statistical parameters developed specifically for this 
study. 



A. PHASE 1 

A satellite pass from NOAA-9 made on July 13, 1987 off of the West Coast of North 
America (Figs. 1, 2 and 3) was chosen as the initial test image because it was found to 
contain a large number of shiptracks of varying lengths, widths and brighmess and 
covered a significantly large ocean area. Hard copies of these files were made using a 
Tektronix RGBII laser printer in the IDEA lab on which the shiptracks were located, 
n umb ered and highlighte d manuall y. 

Locating, highlighting and numbering the shiptracks on the hard copies was 
necessary in order to subjectively create a standardized image to be compared to each run 
of the algorithm. The procedure involved painting (an Avian utility where 512x512 
portions of an overview are blown up in full resolution and viewed) the overview and 
hand drawing the shiptracks seen on the screen onto the hard copies. Locating the 
shiptracks on the monitor and then hi ghli ghting and numbering them on the hard copies 
was necessary due to the poor resolution of the hard copies themselves. 

Each time the algorithm was run, a giant byte file was created. These files were 
converted to integer files and condensed, much like the giant image files were, \ising a 
program called fixcondO. By making transparencies of these output files and overlaying 
them on the image hard copies, the detections and false detections of each nin were easily 
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and unambiguously noted. The optimum settings were selected based on the number of 
shiptracks detected and the niunber of false detections made. 

With 20 control parameters available, in theory, a large number of possible setting 
combinations is possible. Fortunately, prior work on a previous 512x512 version of the 
algorithm established a few of the settings used in Census and Neighborhood, leaving 17 
relatively imtested parameters. An additional 3 parameters from Gravel were assumed to 
have only minimal effects on the algorithm efficiency and were left out of the testing. 
This left 14 untested control parameters that were assumed to play a major role in the 
algorithm efficiency (see Table 4). 

B. PHASE 2 

Once the optimum settings of the algorithm were determined, the attention was 
shifted towards testing the algorithm efficiency on suitable alternate satellite passes. The 
first image to be analyzed with the optimmn settings after the original test image was a 
Low3 (vice channel 3) version of the original test image. Preparing this pass for the 
algorithm involved re-running the Datadump and real2bye programs to create a Low3, 
giant output file to be used instead of the channel 3 file. After the algorithm was run and 
the 



34 



TABLE 4 

TESTED CONTROL PARAMETERS 



Setting 


Description 


1 

Subroutine 


Thigh 


Maximum channel 4 temperature reading of 
the potential shiptrack segment. 


Census 


Tlow 


Minimum channel 4 temperature reading of 
die potential shiptrack segment. 


Census 


Radius 


Maximum search radius to find connecting 
neighborhood representative. 


Roadway 


Thresh3(l) 


Channel 3 path/full field minimum brighmess 
contrast. 


Pave 


Thresh3(2) 


Channel 3 sub/far field minimum brighmess 
contrast. 


Pave 


Thresh3(3) 


Channel 3 near/far field maximum brighmess 
contrast. 


Pave 


Pathresh 


Minimum percentage of path perpendiculars 
that must pass the Thresh3 tests. 


Pave 


Pathgrad 


Minimum channel 3 brighmess gradient 
across the path segment. 


Landscape 


Thresh3wd 


Minimum percentage of path perpendiculars 
that must pass the Pathgrad test. 


Landscape 


Gravl 


Minimum channel 1 brighmess value of the 
potential shiptrack segment. 


Gravel 


Bogus 1 


Minimum percentage of path perpendiculars 
that pass pathkept 1 tests. 


Gravel 


Bogus2 


Minimum percentage of path perpendiculars 
that pass pathkept 4 tests. 


Gravel 


BogusS 


Minimum path channel 4 gradient average 


Gravel 

1 1 


Bogus6 


Minimum path channel 1 gradient average | Gravel 
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subsequent analysis completed on this image, three additional passes were chosen and 
prepared in an identical manner to that in which the original test image was in phase 1 . 
This preparation included creating the giant input files and hand drawing the shiptracks 
on the channel 3 image hard copies. Once the subjective analysis was complete on each 
pass, the detection algorithm was run and the output files analyzed. 

Although the algorithm was not specifically designed to pick up any specific region 
of a generic shiptrack, during the analysis a distinction was made between the head region 
of a shiptrack the rest of the track segment. Shiptracks whose heads were visible on the 
image were categorized separately from those that did not, and shiptrack detections that 
included the head region of a shiptrack (to within a 20 km error margin) were noted. This 
emphasis on the shiptrack heads was done based on the assumption that the head of a 
shiptrack is the most recently formed part of the track and is therefore much less 
susceptible to dispersion and wind shears that influence the track down wind of the 
formation region. Additionally, the head, or formation region, of a shiptrack is the most 
critical part of the track for the purposes of both formation mechanism studies and ship to 
shiptrack correlation smdies. 

The analysis process involved collecting data from both the channel 3 and the 
algoritiim output images and performing a series of simple statistical calculations intended 
to present the effectiveness of the algorithm on each run. The types of data collected on 
each run are listed in Table 5. The performance statistics developed to present the 
algorithm efficiency outlined in Table 6. 
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TABLES 



DATA COLLECTED FOR EACH 
SATELLITE PASS 



NS = 


0 Number of ST subjectively observed 


NH = 


*Number of HT subjectively observed 


SL = 


“Total length of observed ST 


HL = 


oTotal length of observed HT 


OA = 


Total open ocean area in Km^ x 10^ 


DATA COLLECTED FOR EACH 
ALGORITHM RUN 


STD = 


Number of ST objectively detected 


HID = 


Number of HT objectively detected 


NHD = 


•Number of ST heads detected 


STL = 


Total detected ST length 


SHL = 


Total detected HT length 


NFD = 


Number of false detections 



OST = shiptracks 

*HT = shiptracks with clearly visible heads 

oBasedon 1 pixel = 1.1 km 

•Shiptrack detection within 20km of head location 



37 



TABLE 6 

ALGORITHM PERFORMANCE STATISmCS 



*ST detection rate (SR) = 

0 STH detection rate (HR) = 
ST length percentage (SL) = 
STH length percentage (HL) = 
ST dectection confidence (SC) = 
False detection rate (FR) = 
Head detection rate (HD) = 
False detections per area (FD) = 



STD/NS 

HTD/NH 

STTL/SL 

SHL/HL 

STD/(SrrD + NFD) 
NFD/(STD + NFD) 
NHD/SIH 
NFD/OA 



* Denotes shiptrack 

0 Denotes shiptracks with clearly visible heads 
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V. RESULTS 



A. PHASE 1 

The objective of phase 1 of the project was to determine the optimum algorithm 
control parameter settings. The first step in determining how well any particular setting 
combination effects the algorithm's performance was creating a subjective shiptrack 
analysis from which to score each individual run. Such a standardized subjective 
shiptrack analysis was performed on the initial test image in accordance with the steps 
outlined in chapter 4. Channel 3 images of the northern and southern half of the original 
test image is presented in Figs. 9 and 10. Recall the northern half of this pass was used 
earlier to illustrate the appearance of shiptracks in the visible, near-IR and thermal-IR 
c hann els (Figs. 1, 2 and 3). The subjective shiptrack analysis for this pass is presented 
by Figs. 1 1 and 12. This analysis was then used as "ground truth" in scoring individual 
algorithm runs as described in chapter IV. 

The next step in the project involved logically choosing appropriate control 
parameter setting combinations, running the algorithm and analyzing the results. By the 
time this smdy had begun, a 5 1 2 x 5 1 2 version of the basic algorithm had been in 
existence for almost a year and the optimum control parameter settings already generally 
determined. These initial settings provided a good starting point for the first phase of the 
project. 
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The initial objective of the first run of the algoritlim on the test image was to 
determine how well the algorithm perfonned with the standardized control parameter 
settings. From the second run on, setting combinations were altered and/or interiial 
modifications made to the code in an attempt to either improve specific perforatance 
characteristics or dete rmin e the effect an alteration of one or more of the control 
parameters had on the output. A separate 512x512 version of the algorithm was updated 
and was used to pre-check many of the changes on small regions of the full pass. 

Table 7 outlines the specific performance results and control parameter settings of 
each run conducted in this phase of the research. Col umns of Table 7 describe valid 
shiptrack detections (Det), false detections (F/D) and all of the tested control parameters 
discussed in chapters HI and IV. Also shown are specific mtemal changes that were 
made to the algorithm between runs. In all, 1 8 runs of the algorithm were made, the last 
two of which were determined to present the optimum control parameter settings/intemal 
code modifications for the algorithm. 

The first of the internal modifications made, listed as "Landscape logic error" in 
Table 7, refers to a logic error that was found within the code that defaulted the main 
do-loop in the Landscape subroutine. The error caused Landscape to be more restrictive 
in its path acceptance tests than intended. On a run of the 512x512 version of the 
algorithm immediately following the logic error correction, the algorithm was found to be 
much less discriminating in its path segment testing, finding an increased number of valid 
shiptracks as well as false detections. This finding was confirmed on the full pass run 
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(number five) which found 28 valid shiptracks and produced 23 false detections. The 
increased number of firlse detections prompted a second series of internal modifications to 
the code intended to increase the algorithm's filter efficiency without sacrificing the vahd 
detection rate. 

The second internal change, listed as "Grove/ modification" in Table 7, was an 
attempt to eliminate a specific recurring false detection off the coast of Southern 
California. The feature causing the false detection was an anomalously bright ridge in an 
otherwise broadly sloping brightness field of medium high cloud, fhe modification 
changed one of the path perpendicular requirements within Gravel's Pathkeptl tests (Fig. 
7). Originally, each path perpendicular was required to have a Subl field brighter than 
Farlave (Fig. 6 and Table 3), The change required that each path perpendicular have a 
Subl field brighter than both the Far-A and Far-B. This change was found to help 
eliminate certain false detections but overall produced an unacceptable decline in the valid 
shiptrack detection rate and was subsequently reversed. 

The third change, listed as "Landscape modification" in Table 7, was made at the 
same time as the Gravel Modification (above) and refers to a lowering of the minimum 
pathwidth accepted in the Landscape subroutine from 5 to 3 pixels. This change was 
made in an attempt to allow the algorithm to pick up more shiptrack heads. The change 
was determined successful and was kept for all subsequent runs. 
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TABLE 7 

PERFORMANCE SUMMARY AND 
CONTROL PARAMETER SETTINGS 
JULY 13, 1987 TEST IMAGE 



Run 


Pet 


F/D 


A 


B 


C D 


E 


F 


G 


H 


I 


1 


22 


8 


278 


291 


50 1 


8 


88 


80 


8 


80 


2 


30 


16 


278 


291 


50 2 


8 


88 


80 


8 


80 


3 


27 


8 


273 


299 


50 2 


8 


88 


80 


8 


80 


4 


27 


10 


273 


299 


45 1 


5 


90 


75 


5 


70 










Landscape logic error corrected 


5 


28 


23 


273 


299 


45 1 


5 


90 


75 


5 


70 










Gravel/Landscape modifications made 


6 


23 


5 


273 


299 


45 1 


5 


90 


75 


5 


70 


7 


24 


6 


273 


299 


50 1 


6 


90 


75 


- 


- 


8 


24 


11 


273 


299 


50 1 


5 


100 


70 


- 


- 












Gravel modification reversed 




9 


29 


20 


273 


299 


50 1 


6 


90 


75 


- 


- 


10 


27 


19 


273 


299 


50 1 


6 


90 


75 


5 


75 


11 


23 


7 


273 


299 


50 1 


8 


90 


90 


- 


- 












New Landscape 


test added 




12 


25 


9 


273 


299 


50 2 


7 


250 


70 


5 


70 


13 


25 


10 


273 


299 


50 1 


8 


150 


70 


5 


70 


14 


20 


8 


273 


299 


50 2 


8 


88 


65 


5 


70 


15 


25 


9 


273 


299 


50 2 


8 


150 


70 


5 


70 


16 


25 


11 


273 


299 


50 2 


8 


150 


70 


5 


60 


17 


28 


11 


273 


299 


50 2 


10 


250 


65 


10 


70 


18 


25 


5 


273 


299 


55 2 


8 


88 


80 


8 


80 










A = 


Thigh 






H = 


= Pathgrad 










B = 


flow 






1 = 


Thresh3wd 










C = 


Radius 








Gravl 












D = 


ThreshS(l) 




K = 


= Bogus 1 










E = 


Thresh3(2) 




L = 


■ Bogus! 










F = 


Thresh3(2) 




M = 


= Bogus5 










G = 


Pathresh 




N = 


= Bogus6 



J 


K 


L 


M 


N 


70 


60 


60 


50 


10 


70 


60 


60 


50 


10 


70 


60 


60 


50 


10 



70 


60 


60 


50 


10 


70 


60 


60 


50 


10 


70 


60 


60 


50 


10 


70 


60 


60 


50 


10 



70 


62 


60 


50 


10 


75 


62 


60 


50 


10 


70 


62 


62 


60 


10 



70 


63 


60 


50 


10 


70 


63 


60 


50 


10 


90 


63 


60 


30 


10 


70 


63 


60 


50 


10 


70 


63 


60 


50 


10 


50 


63 


60 


70 


7 


70 


60 


60 


50 


10 



*Blanks in columns H ;ind I denote Landscape subroutine turned olT 
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The last modification listed as "New Landscape” in Table 7, refers to a test added to 
the Landscape subroutine that rejects potential shiptrack path segments that have 
excessively noisy brighmess gradients. This test was determined to be successful in 
increasing the Landscape filter efficiency and was kept for all following runs. The logic 
specifics of this test are described fully in the Landscape section of chapter HI. 

The final two runs conducted in phase 1 were selected as representing optimum 
control parameter settings based on the algorithm's performance on the single test image. 
Run 17 settings (hereafter referred to as Run A settings) produced a high number of 
detections with a moderate number of false detections (Figs. 13 and 14). This setting 
combination can be considered optimum when the number of false detections made by the 
algorithm is not as critical an issue as the number of detections. Run 1 8 (hereafter 
referred to as Run B) settings on the other hand produced a moderate number of false 
detections. The Run B setting combination was found to be the most conservative and 
could be used when the number of false detections is as least as critical as the number of 
detections made (Figs. 15 and 16). 

The sub-algorithms which call the various control parameters that were tested in 
phase 2 can be thought of faUmg into two general categories: Those that search for 
potential shiptrack path segments and those that perform acceptance tests on the path 
segments found. Run A settings are designed to be somewhat relaxed in their shiptrack 
path segment search thresholds (Table 7 columns D through G) but relatively strict in 
their acceptance tests thresholds (Table 7 columns H through N). Recall from chapter HI 
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that parameters D, E, and F are channel 3 brightness thresholds used in Pave to ensure 
potential shiptrack path segments are sjifficiently brighter than the adjacent cloud field. 
Parameter G is the minimum percentage of the potential path segment that must meet 
these brighmess criteria. Parameters H and I are used in Landscape as filter parameters. 
H is the minimum shiptrack pathedge gradient allowed by Landscape and I is the 
percentage of path perpendiculars that must meet the minimum gradient standards. The 
remaining parameters are used in Gravel (Fig 7). Parameter J is the minimum channel 1 
brighmess threshold of the shiptrack path segment Parameters K and L represent the 
minimum percentage of the shiptrack path perpendicular that must meet the various 
channel 1 and 3 brightness and gradient tests. Finally, parameters M and N are the 
minimum average channel 1 and 4 path segment gradients. 

In contrast to Run A, Run B settings are more strict in their search thresholds (D 
through G) but less restrictive in their acceptance test tiiresholds (H through N) than Run 
A. This difference in approach to finding valid shiptracks is the cause for the 
dissimilarities between the output runs using Run A and Run B settings. 



B. PHASE 2 

The additional sateUite passes chosen for the second phase of the project came from 
the FIRE tape library in the IDEA lab. The images were taken by NOAA-9 and 10 in 
the summer of 1987 and are aU centered off of the West Coast of North America. 
Specific dates are as follows; June 27, July 7, July 8. 
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1. Case study I 

The same July 13, 1987 pass that was used as the original test image in phase I was 
also used as the first case study in phase 2. Figures 9 and 10 are condensed (every foiuth 
pixel) channel 3 images of the northern and southern halves of the full satellite pass. 
Although of reduced resolution, a majority of the shiptracks subjectively observed can be 
seen. Figures 1 1 and 12 show the subjective sbiptrack analysis made on this pass, 1 1 
being the northern and 12 the southern half. Tables 8 and 9 summarize the subjective jmd 
algorithm run findings for the channel 3 and low3 versions of the July 13 case study. 

Forty shiptracks were observed (NS) in the subjective analysis of this image, 23 of those 
falling into the category of having clearly defined heads (NH). Figures 13 and 14 show 
the algorithm (Run A settings) output for the northern and southern halves respectively. 
Overall Run A produced 39 detections, 28 of which corresponding to valid shiptracks 
(STD), and detected roughly 38% of the total shiptrack length (STL/ST). The Run B 
settings (Figs. 15 and 16) were slightly more conservative, producing 30 detections (25 of 
which corresponding to valid shiptracks) and detected roughly 31% of the total shiptrack 
length. Runs A and B on the low3 version of the pass (Table 9) did not score as well as 
their channel 3 counterparts, in each case producing a smaller number of detections while 
maintaining similar valid to false detection ratios. Detected tracks from the low3 version 
are illustrated on Figs. 17 through 20. 
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2. Case Study 2 

The June 27 pass shows an extraordinary number of shiptracks concentrated in a 
relatively small area off of the coast of North America. A total of 52 shiptracks are 
observed, 44 of which had clearly visible heads. Figure 21 shows the condensed c hann el 
3 image of the northern half of the pass (no shiptracks were observed in the southern half 
of the image) while Fig. 22 presents the subjective analysis made on that portion of the 
image.. Figures 23 and 24 are the algorithm output files from Runs A and B. Table 10 
summarizes the findings from both the subjective analysis and the algorithm runs from 
this case study. Contrary to the findings in the first case study, both runs found the same 
number of valid shiptracks (STD=27), although not necessarily the same shiptracks, with 
Run A actually finding a fewer number of false detections (NFD=6) than Run B 
(NFD=7). S imilar to the first case study however, Run A detected a higher percentage of 
total shiptrack length (STL/ST) than Run B (19% to 21% respectively). 

3. Case study 3 

In general, shiptracks did not appear on the July 7 pass. Although 19 shiptracks are 
subjectively observed, very few had the brightness and clarity observed in the previous 
two passes. Additionally, the image shows a large number of north-south running cloud 
edges in the low sun angle, southeast most portion of the image and consequently was an 
area of high false detections. Figures 25 and 26 show the condensed channel 3 images of 
the northern and southern halves of the pass respectively and Figs. 27 and 28 show the 
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subjective shiptrack analysis made on each. The reader should be reminded tliat the tnird 
copy figiu^s do not display all the detail of the digital data and the overview images have 
reduced resolution (every fourth pixel) compared to the complete subsccne. 

Consequently many of the subtle shiptracks are not obvious in the overview figures. Run 
A (Figs. 29 and 30) produced a higher number of detections and found a greater 
percentage of total shiptrack length than Run B (Figs. 31 and 32). Run B, however, had 
a higher valid to false detections rate than did Run A. The specific findings of each run 
along with the subjective shiptrack analysis statistics are summarized in Table 1 1 . 

4. Case study 4 

Figs. 33 and 34 show the condensed channel 3 images from the July 8 pass, 
northern and southern halves respectively. The subjective shiptrack analysis for these 
images are shown in figs. 35 and 36. Again, this image showed few bright and 
continuous shiptracks as compared with case studies 1 and 2. A total of 16 shiptracks 
were observed, 13 of which had clearly visible heads. Runs A (figs. 37 and 38) and B 
(figs. 39 and 40) performed slightly better than the July 7 and are summarized along with 
the subjective analysis statistics in Table 12. 

5. Summary 

The data outlined in the Tables 9 through 1 2 was used to compute the perfonn-ance 
statistics as outlined in chapter IV. fhese statistics are presented in fable 13. llie table 
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is broken down into Run A and B settings, last row in each section, labeled 
"combination", was computed using the combined number of shiptracks, shiptrack length 
etc. from each nm within that section. ITie values in this column can be thought of as the 
weighted average value from each run. 

In general, algorithm runs using Run A settings detected a higher percentage of 
shiptracks with clearly visible heads than Run B (65% and 58% respectively) and a 
greater percentage of these shiptrack lengths (26% and 23 %). At the same time 
however. Run A settings scored lower shiptrack confidence rates than Run B (63% to 
72%), producing an average of 1.31 false detections per million square kilometers as 
compared to an average of only 0.87 false detection per million square kilometers for Run 
B settings. 

C. FALSE DETECTIONS 

Algorithm false detections per unit ocean area were pleasingly low. Many of the 
features causing false detections were small (usually under 50 km in length) but 
nonetheless tulfilled each of the algorithm objective shiptrack tests. A small handful of 
the features could not be identified and fell into a categorical description of anomalous 
cloud features. The majority of the remaining false detections fell into four general 
categories; 1) Cloud edges in low sim angle regions, 2) Thin, elongated stratoform 
clouds over water (especially near the edges of the satellite pass), 3) Gravity wave 
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interactions with the marine boundary layer, and 4) Old shiptrack remnants. Examples of 
the first three categories are given in figs. 41 through 43. 

Figure 41 shows a full resolution (512x512 .subscene) chaimel 1 and 3 image of a 
north-south running cloud edge in the low sun angle region of the July 7 pass. A bright, 
linear feature is clearly seen in the channel 3 image along the eastern edge of the low 
cloud centered in the image. This feature is on the same order of magnitude as a 
shiptrack and produced a false detection on both algorithm runs. Currently no adequate 
filter has been designed to stop the algorithm from detecting such features. 

Figure 42 is a full resolution channel 1 and 3 image taken near the edge of the July 8 
satellite pass. This image shows apparently thin bright clouds in both channels 1 and 3 
surrounded by darker adjacent clouds. Because this view is at the edge of the sateUite 
pass, the oblique view is grossly distorted and these clouds are actually much wider than 
they appear. This feature produced a false detection on both algorithm runs on the July 8 
pass. A potential algorithm modification that would vary the maximum pixel width of 
accepted shiptracks as a function of the number of degrees off nadir the feature is located 
may provide a means of eliminating this particular problem. 

Finally, Fig. 43 shows both a channel 1 and channel 3 full resolution image of 
gravity wave phenomenon off of the Baja Peninsula on the July 13 pass. Gravity waves 
force the upper saturated marine boundary layer to come in contact with the dryer air 
above in a sinusoidal pattern. As the saturated air comes in contact with the diyer air, 
the cloud droplets become smaller due to evaporation and consequently, the visible and 
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near-IR reflectance increases. This Ls seen in both ttie channel 1 and channel 3 images. 
This feature produced false detections on both algorithm runs. 

Additional study of the reasons for false detections of shiptracks will produce better 
filters for the algorithm, allowing less restrictive shiptrack search parameters. This will 
ultimately lead to overall improvements in the algorithm's performance. 
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Kii4ure 9. Norlliem half of My 13, 1987 AVHRR c hann el 3 image 
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Figure 10. Southern half of July 13, 1987 AVHRR c hann el 3 image 
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I’igure 1 1. Subjective shiptrack analysis of northern half of July 13. 1087 pass 
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Mgure 12. Subjective shiptrack analysis of southern half of July 13. 1987 pass 
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Figure 13. Algorithm Run A on northern half of July 13, 1987 pass. 
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figure 14. Algorithm Run A on southern half of July 13, 1987 pass. 
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[' igure 15. Algorithm Run B on northern half of July 13, 1987 pass. 
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Figure 16. Algorithm Run B on southern half of July 13, 1987 pass. 
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Figure 17. Algorithm Run A on Low3 version of northern half of July 13, 1987 pass 




Figure 18. Algorithm Run A on Low3 version of southern half of July 13, 1987 pass 
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Figure 19. Algorithm Run B on Low3 version of northern half of July 13, 1987 pass 




Figure 20. Algorithm Run B on lx)w3 version of southern half of July 13, 1987 pass 
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TABLE 8 
JULY 13, 1987 

SUBJECTTVE AND ALGORITHM 
DETERMINED STAllSllCS 

SUBJECTIVE STA nSTTCS 



NS -40 
NH = 23 
ST =8450 
HL=4680 
OA =8.40 



RUN A STATISTICS 



STD = 28 
HTD = 21 
NHD = 16 
STL =3215 
SHL = 2575 
NFD = 11 



RUN B STATIS nCS 



STD = 25 
HTD= 18 
NHD= 14 
SDL =2595 
SHL = 2015 
NFD = 5 



NS = 


Number of ST subjectively observed 


NH = 


Number of HT subjectively observed 


SL = 


Total length of observed ST 


HL = 


Total length of observed HT 


OA = 


Total open ocean area in Awi^xlO^ 


STD = 


Number of ST objectively detected 


HTD = 


Number of HT objectively detected 


NHD = 


Number of ST heads detected 


STL = 


Total detected ST length 


SHL = 


Total detected HT length 


NFD = 


Number of false detections 
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TABLE 9 

JULY 13. 1987 (LOW3) 
SUBJECTIVE AND ALGORITHM 
DETERMINED STA TISTICS 

SUBJECTIVE STA nSHCS 



NS = 40 
NH = 23 
ST =8450 
HL = 4680 
OA =8.40 

RUN A STAHSHCS 



STD = 25 
HTD= 19 
NHD= 13 
STL =2645 
SHL= 1625 
NFD = 9 



RUN B STATISHCS 



STD = 20 
HTD= 16 
NHD= 11 
STL =2090 
SHL= 1235 
NFD = 4 



NS = 


Number of ST subjectively observed 


NH = 


Number of HT subjectively observed 


SL = 


Total length of observed ST 


HL = 


Total length of observed HT 


OA = 


Total open ocean area in km^ X 10^ 


STD = 


Number of ST objectively detected 


HTD = 


Number of HT objectively detected 


NHD = 


Number of ST heads detected 


STL = 


Total detected ST length 


SHI. = 


Total detected HT length 


NFD = 


Number of false detections 
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Figure 21. June 27, 1987 AVHRR channel 3 image 
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Figure 22. Subjective shiptrack analysis of June 27, 1987 pass 




Figure 23. Algorithm Run A of June 27, 1987 pass. 
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Figure 24. Algorithm Run B of June 27, 1987 pass. 



TABLE 10 
JUNE 27, 1987 

SUBJECTIVE AND ALGORITHM 
DETERMINED STA'llS ITCS 

SUBJECTIVE STATTSTTCS 

NS - 52 
NH = 44 
ST - 15620 
HL= 14400 
OA =7.32 

RUN A STATISTICS 



SID = 27 
HID = 25 
NHD = 15 
STL = 3255 
SHL-3205 
NFD = 6 



RUN R SJ ATISTTCS 



STD = 27 
HTD-24 
NHD= 14 
STL- 3035 
SHL-2925 
NFD = 7 



NS = 


Number of ST subjectively observed 


NH = 


Number of HT subjectively observed 


SL = 


Total length of observed ST 


HL = 


Total length of observed HT 


OA = 


Total open ocean area in hn} x 10® 


STD = 


Number of ST objectively detected 


HID = 


Number of HT objectively detected 


NHD = 


Number of ST heads detected 


STL = 


Total detected ST length 


SHL - 


Total detected HT length 


NED = 


Number of false detections 



\ 
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Figure 25. Northern half of July 7, 1987 AVHRR c hann el 3 image 
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Rgure 26. Southern half of July 7, 1987 AVHRR chaimel 3 image 
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Figure 27. Subjective shiptrack analysis of northern half of July 7, 1987 pass 




Figure 28. Subjective shiptrack analysis of southern half of July 7, 1987 pass 
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Figure 29. Algorithm Run A on northern half of July 7, 1987 pass. 
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Mgure 30. Algorithm Run A on southern half of July 7, 1987 pass. 
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Figure 31. Algorithm Run B on northern half of July 7, 1987 pass. 
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Figure 32. Algorithm Run B on southern half of July 7, 1987 pass. 



TABLE 1 1 
JULY 7, 1987 

SUBJECTIVE AND ALGORITHM 
DETERMINED STAHS'IICS 

SUBJECTIVE STATISTICS 



NS= 19 
NH= 13 
ST = 4610 
HL = 3640 
OA =8.35 

RUN A STATISTICS 

STD = 9 
HTD = 6 
NHD = 2 
STL = 970 
SHL = 840 
NED = 14 



RUN B STATISTICS 



NS = 


STD = 8 
ITID=5 
NHD = 2 
STL = 940 
SHL = 810 
NED = 12 

Number of ST subjectively observed 


NH = 


Number of HT subjectively observed 


SL = 


Total length of observed ST 


HL = 


Total length of observed HT 


OA = 


Total open ocean area in hn} x 10^ 


STD = 


Number of ST objectively detected 


HTD = 


Number of HT objectively detected 


NHD = 


Number of ST heads detected 


STL = 


Total detected ST length 


SHL = 


Total detected HT length 


NED = 


Number of false detections 
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Figure 33, Northern half of July 8, 1987 AVHRR channel 3 image 
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Figure 34. Southern half of July 8, 1987 AVHRR channel 3 image 
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Figure 35. Subjective shiptrack analysis of northern half of July 8, 1987 pass 




Figure 36. Subjective shiptrack analysis of southern half of July 8, 1987 pass 




Figure 37, Algorithm Run A on northern half of July 8, 1987 pass. 
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Figure 38. Algorithm Run A on southern half of July 8, 1987 pass. 




Figure 39. Algorithm Run B on northern half of July 8, 1987 pass. 
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Figure 40. Algorithm Run B on southern half of July 8, 1987 pass. 



TABLE 12 
JULY 8, 1987 

SUBJECTIVE AND ALGORITHM 
DETERMINED STATISTICS 

SUBJECTIVE STATISTICS 



NS= 16 
NH = 13 
ST = 5725 
HL=5130 
OA =5.55 

RUN A STATISTICS 



STD = 7 
HTD = 4 
NHD = 4 
STL = 650 
SHL = 300 
NFD = 10 



RUN B STATISTICS 



STD = 6 
HTD = 4 
NHD = 4 
STL =695 
SHL= 595 
NFD = 5 



NS = 


Number of ST subjectively observed 


NH = 


Number of HT subjectively observed 


SL = 


Total length of observed ST 


HL = 


Total length of observed HT 


OA = 


Total open ocean area in x 10^ 


STD = 


Number of ST objectively detected 


HTD = 


Number of HT objectively detected 


NHD = 


Number of ST heads detected 


STL = 


Total detected ST length 


SHL = 


Total detected HT length 


NFD = 


Number of false detections 
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TABLE 13 

ALGORITHM PERFORMANCE 
STATISTICS 



RUN A SETTINGS 



Run 


SE 


m 


SL 




SC 


m 


m 


FD 


13JuIA 


72 


91 


38 


55 


72 


28 


70 


1.31 


LowA 


63 


83 


31 


35 


74 


26 


57 


1.07 


27JunA 


52 


55 


19 


20 


79 


21 


32 


0.96 


7JulA 


47 


46 


21 


23 


39 


61 


15 


1.68 


8JulA 


44 


31 


12 


10 


54 


46 


31 


0.90 


Combined 


57 


65 


25 


26 


63 


37 


43 


1.31 








RUN B SETTINGS 








13JuIB 


63 


78 


31 


43 


83 


17 


61 


0.60 


LowB 


50 


70 


25 


26 


83 


17 


48 


0.48 


27JunB 


52 


57 


21 


22 


82 


18 


34 


0.82 


7JuB2 


42 


38 


20 


16 


40 


60 


23 


1.44 


8JulB 


38 


31 


11 


10 


41 


59 


31 


1.80 


Combined 


51 


58 


22 


23 


72 


28 


39 


0.87 



SR = *ST detection rate 

HR = 0 STH detection rate 

SL = ST length detection percentage 

HL = STH length detection percentage 

FR = False detection rate 

SC = ST detection confidence 

HD = Head detection rate 

FD = False detections per km?- x 10* 



*ST denotes shiptrack 

OSTH denotes shiptracks with clearly visible heads 
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Figure 41. Natural cloud feature that produced algorithm false detections: North-south 
aligned cloud edge preferentially illuminated by the sun in the near-IR in a low sun angle 
region of the July 7 pass. Top image is channel 1. Bottom image is channel 3. 
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Figure 42. Natural cloud feature producing algorithm false detections: Relatively thin 
cloud streaks over water near the edge of the July 13 pass. Top image is channel 1. 
Bottom image is channel 3 
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Figure 43. Natural cloud feature producing algorithm false detections; Gravity wave 
interaction with marine boimdary layer. Top image is channel 1 . Bottom image is 
channel 3 
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VI. CONCLUSIONS AND RECOMMENDATIONS 



The goal of this project was to quantitatively determine the performance of the most 
recent version of a shiptrack detection algorithm. The statistics are prepared from the 
author's subjective analysis of the four satellite passes. Many times during the subjective 
analysis, a feature that possessed all the right shiptrack characteristics in terms of channel 
1, 3 and 4 brightness, gradients and temperatures, was rejected simply because it didn't 
look like a shiptrack. Clearly, this subjectivity must be taken into account when 
reviewing absolute numbers describing the algorithm's performance. 

Overall, the algorithm performed as designed, detecting the majority of the shiptracks 
without producing excessively high numbers of false detections. The performance 
characteristics of the two chosen ’’optimum” control parameter settings fluctuated from 
pass to pass, generally perfonning better on those cases having a large number of bright 
shiptracks (July 13 and June 27) than those with less bright and fewer shiptracks (July 7 
and 8). Run A settings consistently detected a higher number of shiptracks than Run B 
settings but consistently produced a higher false detection rate. 

The low3 version of the July 1 3 case was less successful than the original channel 3 
version. In the near-IR, the low3 image did not show the shiptracks as well as the 
channel 3 image. The cause for this difference is not clear and deserves further study. 
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A. FALSE DETECTIONS 



Much can be learned from a closer examination of algorithm false detections. In 
every case, of course, features causing false detections fit the coded description of 
shiptracks. In each case the feature was subjectively rejected as fitting into one or more 
of the categories of naturally occurring cloud line features. With further research, it may 
be possible to find specific characteristics in common to many of these the features (but 
not conunon to shiptracks in general) and use characteristics to build specific filters into 
the algorithm designed to reject these naturally occulting features, Once in place, these 
filters would allow the acceptance parameters within the algorithm to be more relaxed, 
thus allowing more potential shiptracks to get through to the filters. Building more 
efficient filters and testing more potential shiptrack path segments would enhance the 
performance of the algorithm. 



B. ALGORITHM MODIFICATIONS 

There are many places within the code where empirical limits govern how shiptracks 
are defined and how they are tested. One such place is within the subroutine Pave, where 
the shiptrack path is defined to be 7 pixels wide and is compared to regions in the 
adjacent cloud field as part of the subroutine's acceptance tests. This approach generally 
fails towards the tail region of a shiptrack where the cloud line becomes significantly 
wider than 7 pixels or near the head where it may be less than the maximum resolution of 
the image (1.1 km). 
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An alternate approach to this particular problem is to define the shiptrack patli as the 
region within the minirnmn and max imum channel 3 gradients as apposed to an arbitrary 
constant width. Such an approach would decrease the niraiber of tests needed in Pave to 
one simple requirement that the path be brighter than the adjacent cloud field. This idea 
is presently in the testing phase and looks promising. 

A second proposal is increasing the maximum allowable path segment length to 
approximately 100 km and incorporating variable Pave, Gravel and Landscape path 
perpendicular percentages based on path segment length. This may allow a greater 
percentage of longer shiptracks to be detected without sacrificing discriminating tests on 
the shorter features. 

The continuing study of objective shiptrack detection will aid in the analysis of the 
shiptrack phenomenon and lead to a better understanding of the modification of oceanic 
stratus clouds. 
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